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SUMMARY 

The development process which resulted in * "^^partieilar the increased Imomnof non- 
undertaking this development are iscusse , ^ taken to the project is described, 

«»' specification and testing prototypes. Finally 

the main features of the new editor, ZED, are covered. 

key words Text editor Text processing OS/360 EDIT 

INTRODUCTION 

The IBM 370/165 at Cambridge provides batch and timesharing services for academic 
users Earlv in the life of this machine a general-purpose rex. editor was developed 
which would run in both the timesharing and batch environments. This program is 
called EDIT. 1 Its facilities are based on a previous text editor developed in Cambridge 

%mmThe“h P a U t ED IT was put into service^ users continued ,0 suggest extends 
and enhancements. Some of these were included in the program, but after a time 
modification became more and more difficult as the original design was stretched to 
limit. Certain inadequacies were impossible to correct and fina lv a major redesign was 
undertaken. The result was a completely new text editor, called • 

The following sections describe some of the inadequacies of ED , - 

not possible to overcome them without a major redesign, the consl * e ^ n *™° 1 
the design of ZED, the implementation and testing process, and ZED itself. 

INADEQUACIES OF EDIT 

EDIT was conceived as an interactive editor, with non-interactive use a lesser activity, 
mainly required for simple tasks such as incremental editing. However, more and mo 
users began making use of EDIT as a general text manipulation language by means o 
scored sequences of commands which were run on a regular has, .One example - su , h 
use is the maintenance of a list of members of a society, together with associated 
information such as type of membership, address, telephone j^Tused^ m 

various fields are delimited by appropriate character strings 1 ‘ 
extract subsets of this data, such as all the members in a given town. Another common 

use is the Dost-processing of output from other programs. 

Using a text editor in this way may not always be the most efficient solution to th 
problem in tTrmsrf machine resources; however, it is very efficient in human resources 
because the user is working within a familar system where all the data ^immediately 
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readable and debugging can be carried out interactively. These are the same benefits 
that can be obtained by using an interactive programming language such as APL for 
computational problems. A text editor can also be used to implement quick 
experimental versions of text processing algorithms before investing resources in full 
scale implementations. 

While it is possible to do the sort of processing described above using EDIT, in many 
cases the command sequences are very clumsy. There are three main areas in which 
EDIT facilities are lacking: searching, command control and line handling. 

Searching 

In EDIT, the only facilities for searching for a particular line of text are the F and L 
commands, which search for a line beginning with or containing a given string, 
respectively. The ability to find a line NOT containing a given string, or containing any 
one of a number of strings, and the ability to find empty lines were the most often 
requested extensions. 

Command control 

EDIT contains no explicit control commands. Users wanting to test for the presence 
of a string in a line have to do a dummy alteration to the line, and ignore the resulting 
error when the string is not present. This is unsafe as well as clumsy. Explicit control 
commands such as IF and WHILE were frequently suggested. 

The restriction that a repeated group of EDIT commands must be all on one line 
(originally imposed for efficiency reasons) diminished the usefulness of this feature. 

Line handling 

EDIT deals with one line of source text at a time and always moves forwards through 
a source file. The restriction to forward movement was imposed for efficiency and to 
minimize the amount of store used. In practice many operations require two passes 
through the file because of this restriction, thus nullifying any efficiency gains. 
Consequently an enhancement that allowed cheap backward movement was desirable. 

A related facility is the movement of a line or lines from one part of a file to another. 
In EDIT this must be done by writing out the lines to be moved to a disc file and then 
reading them back again which is a comparatively expensive operation. 


UPGRADING CONSIDERATIONS 

This section summarizes the reasoning behind the decision to implement a new editor 
in the same style as EDIT, and describes how the design was carried out. 

Full screen editors 

Since EDIT was first implemented, terminals with screen displays have become 
commonplace on all types of processor. It is widely agreed that the most humanlv 
acceptable form of interactive text editing is by means of a full screen editor which 
displays a page at a time and allows the user to point, by means of a light pen or cursor, 
at the portions of text to be amended. Such an editor requires a device capable of 
operating at high speed in page mode. 

The provision of a full screeen text editor as an upgrade to EDIT was not considered, 
for the following reasons: 
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1. It would be purely interactive rather than general purpose; the deficiencies of 
EDIT are felt most in non-interactive applications. 

2. There are no full screen devices currently attached to the 370/ 16a, and in any case 
such devices are likely to remain in a minority because of cost. 

Imported editors 

Having decided that a more up-to-date editor was desirable, one approach would 
have been to have acquired an existing editor from elsewhere. The reasons for not 
looking for such an editor were twofold. Firstly, it was very important to preserve as 
much compatibilitv with EDIT as possible. There are currently over 2000 registered 
users of the 370/165, many of whom have been using editors in the style of EDI 1 tor 
more than a decade. 5 

Secondly, the unique problems of running under the OS/360 operating system ma 
it highlv unlikelv that software from elsewhere would adhere to local utility standards. 
<\ n editor was required which would run sensibly both interactively and in the batch, 
and would be capable of reading and writing any sequential hie in the system. 

The last point requires some elaboration for the benefit of readers not familiar with 
OS/360. Under this operating system sequential files may be in one of three formats, 
fixed length records, variable length records or undefined length records. In addition, 
the first two tvpes mav be blocked or unblocked, and variable length records may, 
optionally, span physical blocks. The record lengths and block sizes may be chosen 
arbitrarily bv the user, within the physical limits of the peripheral device. A furthe 
complication is that the first character of the records in any given file may optionally be 
designated as a control character, and there are two possible kinds of control character. 

At the level of the interface to the operating system, the programmer must be aware 
of all the possible formats for sequential files, and must write code to deal with each of 
them. Special code is also required for driving terminals in an interactive fashion. A 
consequence of this is that many Assembler programs and high level language systems 
support onlv a subset of the available formats. A truly general purpose editor, however, 
must be capable of dealing with all of them, and must also be capable of converting 

input in one format to output in another. , 

A further implementation restriction was imposed by the fact that the 3/0/165 does 
not have paging hardware, and hence does not offer virtual memory facilities The 
editor therefore has to make minimal demands on main storage, and is required to be 
re-entrant in order to reduce the swapping overhead for interactive users. 

The design process 

The first planning document proposing a major upgrade to EDIT attempted as ar as 
possible to keep a compatible syntax for editing commands. During the discussion 
which followed it became clear that it was impossible to provide aH the required 
enhancements within the old syntax. One of the mam problems was that EDIT allows 
any character as a delimiter for text strings. Thus the F command, which hnds a line 
beginning with a string, could for example be written 

FFABCF 

in order to find the string ABC. As a result of this delimiter rule only one command can 
begin with the letter F. This can, of course, easily (and only slightly incompatibly) be 
overcome bv forbidding the use of letters as delimiters. There still remain problems 
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with special characters if, for example, a way of specifying ‘the last search string’ is 
required. The use of the space character as a delimiter causes difficulties when strings 
are given attributes represented by letters, and these must be separated from the 
command name by spaces. 

The result of the planning discussion was a decision to design a completely new text 
editor, retaining compatibility only where convenient. The processes of design and 
implementation were then carried out in parallel, experience of using the first 
primitive, incomplete versions being fed back into the design. 

The development of the user specification was coordinated by one person. However, 
the many drafts that were produced were widely circulated and comments were 
received from many sources. The implementation was entirely a one-person affair. The 
elapsed time from start to first general release was one year; the estimated time spent on 
the program was six months. Very early in the implementation cycle primitive versions 
of ZED were made available to selected users for evaluation. The first of these consisted 
of little more than the F command. The feedback from this experimental use was 
invaluable in detecting poor design choices as well as program bugs. A number of 
changes were made to the syntax of editing commands, some of them fairly substantial, 
and several commands were respecified as a result of user comments. Such modifi- 
cations were possible because ZED was developed in an environment which 
encourages flexibility. In addition, as it was a redevelopement of an existing facility, 
there was no deadline for its completion. The result of this parallel design and 
implementation is a program whose rougher edges had been removed before release to 
the general user population. 


MAIN FEATURES OF ZED 

This section describes the most important facilities provided by ZED in an informal 
manner. A complete list of editing commands (including many not described in this 
paper) is given as an appendix, while a full specification of the program appears in 
Reference 3. 

ZED commands consist of a command name, which is either a sequence of letters or a 
single special character, optionally followed by arguments. Seven different types of 
argument exist: strings, qualified strings, search expressions, names, numbers, switch 
values and command groups. Commands are delimited by end of line (except within 
parentheses) or the semicolon character. Spaces may occur between a command name 
and the first argument, between non-string arguments, and between commands. A 
space is only necessary in these places to separate two successive items which would 
otherwise be treated as one (e.g. two numbers). The character \ is used to introduce 
comment, terminated by end of line. 

Many commands may be obeyed a fixed number of times by preceding them by a 
count. For example, 

3N 

obeys the N command (which moves to the next line) three times. A sequence of 
commands may be grouped together by enclosing it in parentheses. Such command 
groups may optionally be preceded by a count, may extend over more than one line of 
command input, and may be nested to any depth. Command groups are used as 
arguments for the control commands. 
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S A string in ZED consists of an arbitrary sequence °f cha racte rs^nclosed tr^rnatchiiTg 
delimiters which do not themselves appear m the string. The delimiter character 
any given string must be one of 


+ 


_ * 


? ! 


Some examples of strings are 
The cat / :A = A + B(I): 

preceded bv a sequence of qualifying letters. These place TOttstranra^tiienMtchmg 
process. A string with no qualifiers will match anywhere in a line of source texhbu 
string preceded by B will match only at the beginning of a line. Thus tor example. 

F Jabberwockv/ 

will find a line containing ‘Jabberwockv , but 
F B/slithy toves / 

will only find a line which begins with ‘slithv roves', 

will onlv match a, the end of a line, wh.le a string preceded b> P ».ll on h a 1 

containing precisely the given characters and nothing else. It P is used with a null st g 

" Thequahfier'N can be used in conjunction with other qualifiers, and negates the 
result of the matching test. Thus 
F NB/The sun was shining/ 

it , i 'T , Ei(=> cun was shining’ . Note that this is not the same 

finds a line that does not begin with I he sun was snin g 

as a line containing ‘The sun was shining not at the beginning. 

findsi non-empty line. The qualifier W specifies a ^^^a taler oTa digit wh!ie 

.. a i...... 

involved were uppercased. Thus 

F UW./king / _ . , 

will find lines containing the words ‘king’, ‘KING’ or even ‘KiNg’, but not ‘kingpin or 

th The in qualifier S specifies that lines are to be considered as starting .at the first 
significant (non-space) character. This is most often used in conjunction with the B 
qualifiers when editing indented text. For example, 

F SB/X: = / 

If a string occurs more than once in a line, the second or subsequent occurrences can be 
matched by specifying a numerical qualifier. For examp e, 

2/cat/ 
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matches the second occurrence of ‘cat’ in a line, and hence 
F 2/cat / 

finds a line containing at least two occurrences of the string ‘cat’. 

A matching operation can be restricted to certain character postions in a line by 
means of the column qualifier. 

F [73, 80J/ABCD/ 

searches for a line containing ‘ABCD’ in columns 73-80. 

As well as their use in the F command, as illustrated in the above examples, qualified 
strings are also used to indicate a position in the current line at which textual changes 
are to be made. In these cases the N qualifier is not allowed. For example, 

B UW/king/'Red/ 

causes the text ‘Red’ to be inserted before that point in the current line matched by 
UW/king/. The beginning and the end of the line can be indicated by the qualified 
strings 

II and E/7 

respectively. There is also a qualifier L which causes the search for the string to occur 
leftwards, thus ensuring that the last occurrence in the line is matched. If the current 
line were 

If seven maids with seven mops 
then the command 

B L/seven/twenty-/ 
would turn it into 

If seven maids with twenty-seven mops 

A numerical qualifier can be used with L to match the wth last occurrence of a string. 

Other commands for operating on the current line are A (insert string after), E 
(exchange string), DFA, DFB (delete from after, before), DTA, DTB (delete till after, 
before), LC, UC (force lower, upper case) and SA, SB (split line after, before). 

Whenever a current line is first altered by means of one of the above commands, a 
copy of the original line is taken. At any time before the line ceases to be current the 
original line can be restored by means of the UNDO command. This provides a 
convenient means of recovery from typing errors when editing interactively. 

Search expressions 

Qualified strings may be combined using the operators & (logical and) and | (logical 
or) to form search expressions. Search expressions are always enclosed in parentheses, 
may contain nested parentheses, and may extend over more than one line of command 
input. They are used as arguments to commands which search for or test lines of the 
source. Commands which perform some action on the current line are restricted to a 
single qualified string argument, as described in the previous section. 

The command 

F (/SUBROUTINE/ | /FUNCTION/) 
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• ‘SUBROUTINE’ or ‘FUNCTION' (or both), whereas 
finds a line containing SUBKUU ii-^ 

F (B/king/ & (NE/queen, j /knave/)) , 

finds a fine beginning with ‘king’ and not ending w.th 'queen’ or begmnmg wtth tng 

the size and complexity of search expresses is the amount of 

main store available to ZED. 

The last search expression snbseauent command if & is 

The last obeyed search expression ,s re-accessed m a subsequent 

written for the argument. For example, 

F /Tweedledum./; N; F & 

finds a line containing ‘Tweedledum’, ^^^Q^^ndTsuch as F which take only a 
command using the same argument as the h ^ without arguments, in which 

single search expression argument can in tact De 

case & is assumed. necessarv because F always starts its 

The N command used in the abo\ e exa P design of ZED that this is not an 

search at the current line. It was recognize unlikelv to tvpe redundant 

« tt g s“ d F unrelated ed,,ing 

operation, and should theretoie e in< - u e , <, can usec j f or commands which 

operate^ on the current l^Tnd vvhichr^uire a qualified string argument. For example, 

F /Tweedledum/; E&/Tweedledee/ 
finds a line containing ‘Tweedledum’ and then obeys 

E/Tweedledum/Tweedledee/ 

TV -_ use of & is only valid when the most recently obeyed 
to exchange the two strings /I h & ^ defined & uni positl0 n in the line, 

search expression succeeded, and m succeeui s 

Thus 

F (/red/ I /white/); E&/purple/ . 

is a valid use of &, because whichever string is found will define the point of excha . 

However, 

F (/red/ & /white/); E&/ purple/ 

is invalid, as is 

F N/red/; E&/purple/ 


Control commands and loops commands, which include IF, UL 

ULEOF (unless end of file) 
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and UTEOF (until end of file). The first four apply a search expression to the current 
line to test which control path to follow. For example, 

IF (/cat/ | /dog/) THEN ( 

B[73, 80]//animal/; ?) ELSE D 

tests the current line for one of the strings ‘cat’ or ‘dog’. If either is found the string 
animal’ is inserted in columns 73—80 and the line is verified (? command); if neither is 
found the ELSE branch is taken and the current line is deleted. 

A series of tests on the same line may be written using the connectors ELIF (else if) 
and/or ELUL (else unless). This reduces the number of parentheses required and 
makes the commands easier to read. 

The loop commands repeatedly obey their command group argument while or until 
the search expression matches the current line. The scan for the elements of the search 
expression starts at the beginning of the line for each iteration. There are, however, 
windowing commands for setting a logical line beginning, and these may be used within 
the iterative command group to skip over contexts already dealt with. A simple example 
of the use of a loop command is 

WH / / E &/ / 

which has the effect of changing all multiple spaces in the current line to a single space. 

LTEOF (until end of file) is special in that it exits from the loop w'hen an end of file 
error message would otherwise occur. Thus it can be used in sequences such as 

UTEOF (F/unicorn /; B / 1 *** 1 ; N) 

which will eventually complete when the F command fails at end of file. 

The normal flow of control in loops can be broken by means of the AGP (abandon 
group) command. This has the effect of exiting from the nearest textuallv surrounding 
level of command group parentheses, and any command of which the group is an 
argument. For example, 

WH B /*/ (A/*/ /; N; IFEOF AGP) 

inserts a space after the initial * of successive lines until either a line not beginning with 
* or the end of the source is reached. A repeat count can be used with AGP to exit from 
more than one level. 

Movement through the source 

The N command, which moves to the next line of the source text, has appeared in 
several previous examples. There is also a command P which moves back to the 
previous line. Similarly, corresponding to the F (find) command, which moves 
forwards, there is a BF (backward find) command wLich performs the same operation 
moving backwards through the source. 

ZED implements backwards motion by keeping previous line in main store as long as 
possible before writing them out to the destination file. Backward motion to the start of 
the text is therefore not always possible for large sources. This restriction is imposed for 
reasons of efficiency. It means that no intermediate disc copies of the text are required 
in the majority of editing applications. The maximum number of lines held in store at 
one time depends only on the store available; on the Cambridge svstem w'here about 
30K bytes of store is available for interactive use of ZED, around 500 lines can normally 
be held. 
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A number of other command 8 “ r “ ™ 'tie'll me numbe: rs as arguments. 
“££££ £ .be source is given ~ 

initially in ascending sequence of line nu moved around in the 

inserted lines do no, have line anginal, and can no longer be 

referenced^ to dumber . H«« ~ mmands with line number arguments can always 
demrtoe from the argument in which direction to move. 

Line shuffling f „ Ki n cks of text around, 

ZED provides 16 in-store buffers for t e ^^ P ° jecifv the destination for lines which 
and for replication. The TO comm ™ * " * destination is a queue which is emptied 

and at the end of editing. 

TO BUFF n 

directs lines to buffer n instead of the default queue; 


1 u ... 

~ i jt„_ ni-Vipr than that to which lines are 

“* before Une m by the command 

Im BUFF n 

If m is omitted, the insertion occurs before the current line. A copv of the conte 
buffer can be inserted by the command 

Im COPY n 

r *■ of Klnrks of text. The following example moves 
This feature enables easy replication of b 

lines 10-15 to immediately before line 3 . 


M10 

TO BUFF 3 
Ml 6 
TO 

136 BUFF 3 


\move to line 10 
\ select buffer 3 
\output lines 10-15 
\revert to normal output 
\insert buffer 3 before line 36 


This technique can also be used to m ^ ^ ^ accessed by mov i n g backwards, 
that the insertion point is stlll "\ e$ and in . stor e buffers may be visualized as a 

The system of input and outp q d tes the points, and each wagon 

railway shunting yard where the 1 O c » i 

represents a line of text. This is depic e buffer there is a tunnel which 

At the end of each siding re P r . es *" ' d g which [ s brought into use by the I command 
connects through to the insert s^mg^ this tunnel generates a copy of the 

with a buffer argument. When COPY »s usea 

lines in the buffer instead of moving t e i current lines by selecting the 

The lines in a buffer can also be processed one by one 

buffer as a source using the FROM command. 
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ILine 

a-3 1 

[output file] 


1 
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1 Line 

a -2 1 

ILine b 1 

1 1 

1 Line 

a -1 1 

ILine c 1 
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I / buffer 0 buffers 

!/ 

I [main store] 

I 

/I 
/ I 


INSERT > > I 


I Line a I ***Current Line*** 


I 

FROM> > I 


iLine a+1 I 


I 


ILine a+2 I [input file] 


i 


Figure I . ZED railway analogy 


FROM BUFF n 

has the effect (in railway terms) of connecting a tunnel from the end of the siding for 
buffer n through to a point just before the current line. Commands which move 
forwards through the source then access the lines in the buffer. A dummy end of file is 
generated when the buffer is empty, and the command 

FROM 

may be used to revert to the normal source file. 


Input and output selection 

As well as controlling the in-store buffers, the FROM and TO commands can be 
used to select different input and output files. In this case the argument is a string which 
is an operating system dependent file name. For example, 
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in the case of the TO contend the '^ 0 ^" St^ that 

ee& r t: ^ 

edlstoceattofitlntoanln-stotehuffet. 

For example, 


Ml 000 
TO /DD1/ 
Ml 501 
TO 

CF /DD1/ 
13600 / DD1/ 


\ move to line 1000 

\ output to temporary file 

\lines 1000-1500 queued for Dul 
\ reselect normal output 
\ close file DD1 
\ insert before line 3600 


Space compression redundant spaces from text, for 

A frequent use of a text editor is {or t e r * m u prin ter at a slow and/or narrow 
example, when inspecting data ‘ n “ n ^ d means of the ON command (see the section 
terminal. This can be done in ZED by mea ^ facility is provided. 

Global operations) but because it is so common a special 

The command 

Cb+ • .vhich ensures that all leading and trailing spaces are 

converted to a single space as source lines are read. 

The command 

CS- 

turns compression off. 


Justification i.ictification bv ensuring that all lines 

EDIT contains facilities for ver >' sim P f J ords Simi i ar facilities are provided in 
contain the maximum possible °^ edia tly the relevant command is obeyed 

ZED , but instead of action taking p ^ used whenever a current line is passed 

the justification parameters; are re ™ h Thus justification takes place in parallel with 
in a forward direction or a line is inserted, n j 

other editing activities. fnllmvs . 

The justification commands are as toll 

^ Ln , Tnctified lines will not be longer than n characters. 

Set justification line length to n. Ju 


I 
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paragraphs. A sequence of indented lines can, however, be justified by using the 

command 

RJn m 

which restricts justification to columns n to m. Any lines which contain text outside 
these columns are not justified. 

Global operations 

ZED provides the ability to specify global operations on the source text which are 
carried out in parallel with other editing. The single global command of EDIT has been 
replaced by the three commands GA, GB and GE which act globallv in the same way 
that the A, B and E commands act on a single line. Thus, for example, 

GA/cat/fish / 

changes every occurrence of ‘cat’ into ‘catfish’ in the current line and in all succeeding 
lines until the end of the source is reached or until the global command is cancelled or 
disabled. The command 

GE/cat/catfish/ 

is equivalent. All the features of qualified strings are available in these commands: 
GA UW[60,]/the/y/ 

changes all occurrences of the w'ord ‘the’, in upper or lower case, following column 60, 
by adding the letter ‘y’. 

The facility provided by the G commands is adequate for global changes involving 
simple additions or exchanges. More complicated operations can be specified by means 
of the ON command, w'hich takes as its arguments a search expression and a command 
group. Whenever a line that matches the search expression becomes current during 
fonvard motion, the command group is obeyed. Commands in the group are restricted 
to those that do not move to a different current line. For example 

ON (BS/SUBROUTINE/ | BS/FUNCTION/) (I 

c 

C 

z 

COMMENT /NEW ROUTINE/ 

p 

) 

causes two empty FORTRAN comment lines to be inserted before any statement 
beginning with SUBROUTINE or FUNCTION, outputs a comment to the 
verification file, and verifies the line. The command 

ON B /*/ (WH /**/ E &/*/) 

causes all multiple asterisks to be changed to a single asterisk in lines w'hich begin with 
an asterisk. An ON command may also optionally specify an ELSE command group, 
w'hich is obeyed whenever the search expression does not match a new current line. 

Each global command, whether G type or ON type, is allocated a number when it is 
obeyed. This number can be used as an argument to the DG, EG and CG commands 
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which respectively disable, enable and to apply a global 

:S” e irrH 9 rd , :fl g hnes after the one contain, ng precisely «» *e 

following commands could be used: 

Mn \ move to line 13 

GE/cat/dog/ \ set U P gl ° bal e * change 

Ml9 \move to line IV 

-i \disable global 1 

ONP/«»/ EG1 Venable when «» encountered ^ 

The currently commands, the 

“rbeTof tri: «ch Ilobafhas matched ,s g.ven, 

procedures and command files eil ces of commands for later use. 

“ASS — » p— • The 

PROC SQ (WH /**/ E /**/*/) 
sets up a procedure called SQ, which, when obeyed by 

DO SQ muirinle asterisks. Procedures may be called 

squashes the current line by removing d mav be called recursively. The 

- d “ sh ° W 3nd CanCd Pr ° C 

^ A^equence of ZED commands may be read from a file other than the current 
command file by the command 

The arguments an operating system dependent «le 

5 usmg one o f the forms 

c BUFF n 

The former leases the buffer empty^w'hilethe^atter leaves it^mact/Th^facilitynrieans 

processed, 

Non-Printing Characters characters that are not available on the 

A source text that ,s being ed "usTd Z provides a 

terminal or other device that is , ' d on lines containing a small number of 

special verification command intended _ comman d ? outputs the current line as 

such characters. Whereas the normdvenhcarion s of t . T he first line 

itstands,thespecialver,ficat.oncom.nand.gener^ ^ ^ ^ ^ ^ 

is the current line with specia P the standard escape mechanism on 

'• a'SS— : system are replaced by the escape character 


[ 
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2. Other special characters are replaced by the first hexadecimal digit of their 
EBCDIC value. 

The second line of output contains hyphens under upper case letters, the rest of the 
escape combination under any escape characters, the second hexadecimal digits of any 
other special characters, and spaces in all other positions. Typical verification output 
from the ! command might be 

The King bought @ 0 @ 1 4* 50 
- - @ 5 S 

The escape combinations @@ and @ S represent an @ and a £ character respectively, 
while the hexadecimal 05 is a tab character. 

For editing binary data or data with a high proportion of non-printing characters, 
ZED can operate in hexadecimal mode. This is switched on and off by the X + and X — 
commands. In this mode lines are verified in hexadecimal as a series of eight character 
groups, and command strings referring to textual data must also be expressed in 
hexadecimal. The line used in the above example would be verified as 

E3888540 D2899587 408296A4 8788A340 7C054AF1 F44BF5F0 

and to change ‘The’ to ‘Their’ the command 

A/85/8889/ 

could be used. 

Commands copied from EDIT 

A number of EDIT’s commands are reproduced without any essential change in 
ZED. These include the line number oriented insert, replace and delete commands (I, 
R and D), the commands for operating on individual characters (>, #, ° 0 , S) and the 
margin, window and fixed field commands (MA, MAY, RV, RF and K). 1 


I IMPLEMENTATION 

ZED is written in IBM 370 Assembler, for reasons of size and efficiency. It is, however, 
designed in a structured manner as a series of well-defined procedures with a standard 
interface convention. This discipline has proved very effective in simplifying the 
debugging process. The code of ZED occupies 36K bytes of main storage. A minimum 
of 8K bytes of working storage is required; if more is available ZED uses it for holding 
more of the source in main store. 

The algorithms used in implementing ZED are mostly straightforward in nature, 
with one exception. The algorithm used for searching for a given string in a line of text 
is a modified version of that published by Boyer and Moore. 4 Their algorithm involves 
the use of a table of 256 bytes (for EBCDIC code); in the context of ZED this is too great 
an overhead both in terms of store and in terms of set up time for very short string 
searches. Instead a table of length 256 bits (32 bytes) is set up for each qualified string 
when it is decoded. This table indicates the presence or absence of each character in the 
string, and is used to implement the first feature of the Boyer and Moore algorithm. A 
useful byproduct is that some of the cost of searching for an alphabetic string in either 
upper or lower case can be avoided. 

The code of ZED includes a store manager which works on a first fit basis, with 
amalgamation of contiguous free blocks. The range of sizes of block is relatively 
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restricted and most blocks are small. Fragmentation problems can occur however 
during operations which involve opening and closing files with large blocksizes. Su 

“Tstk ^“tp^t the procedure calling conventions, thus naturally 
providing facilities for recursion which are exploited when processing nested comman 

gr ZED decodes and translates each line of commands into an internal data structure 
before starting to obey the line. This is in contrast to , . - 

ssaasxsssssa^^ — 1 

interactive user is alwavs given the opportunity to enter more commands following an 
error except after internal consistency failures (which should never occur). 

CONCLUSION 

^rom^petesdn^n the^^^^omm unity •ipas'let^toaii'edUoAvltich l^sVapidly^inned 

;^ad™d,v SI several dozen 

USe Th'e m main *« needs of the no, 

intlractTve user Facilittes to enhance programmability have been prov.ded ,n such a 
wav that the interactive user is not unduly penalized. 
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APPENDIX— ZED COMMANDS 


Argument abbreviations: 
a, b 
eg 

m, n 

q 


line numbers (or . or *) 
command group 
numbers 

qualifier list (possibly empty) 
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se 
s, t 
sw 

name 

Qualifiers: 

B 

E 

C 

L 

P 

W 

U 

s 

N 

n 

[n,rn] 

Line selection 


Ma 

M* 

M- 

M + 

N 

P 

F se 
BF se 


search expression 
strings of arbitrary characters 
switch value ( + or — ) 
sequence of letters (4 significant) 


beginning 

ending 

control character 
last 

precisely 

word 

upper case 

significant 

not 

count 

window 


move to line a 
move to end-of-file 
move back as far as possible 
move forward to high water 
move to next line 
move to previous line 
find (forward) 
backward find 


Line insertion and deletion 

Insert material may be any one of 

<(in-line text, any number of lines 
terminated by Z on its own line) 

BUFF n to insert an in-store buffer 

COPY n to insert a copy of an in-store buffer 

/ s/ to insert the file with ddname or dsname s 


la 

Ra b 
Da b 
DF se 
DREST 
DBUFFn 
DBUFF 


insert before line a 
replace lines a to b 
delete lines a to b 
delete find 
delete rest of source 
delete contents of buffer n 
delete contents of all buffers 


Line windowing 

RFn m 
RVn m 

> 


restrict find 
restrict view 

move character pointer to right 
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1 PR 

reset pointer to start 


PA q/s/ 

point after 


| PB q/s / 

point before 


1 EWR 

end window right 


EWL 

end window left 


1 EWA q/s/ 

end window after 

5 

1 EWB q/s/ 

end window before 


i Single character operations 


1 S 

force lower case 


0 

o 

force upper case 

\ 

| <— or_ 

change character to space 

1 

1 # 

delete character 

=; 

1 String operations 


| 

A q/s/t/ 

after 


AP q/s/t/ 

after and point 


) B q/s/t/ 

before 


‘ BP q/s/t/ 

before and point 


E q/s/t/ 

exchange 


! EP q/s/t/ 

exchange and point 


1 DFA q/s/ 

delete from after 


DEB q/s/ 

delete from before 


1 DTA q/s/ 

delete till after 

! 

DTB q/s/ 

delete till before 


LC q/s/ 

force lower case 

■ 

i UC q/s/ 

1 i 

force upper case 


repeat last string operation 


UNDO 

undo current line 


| SHC q/s/ 

show column 


1 CC /s/ 

set control character 


i Splitting and joining 

SA q/s/ 

split after 

1 

SB q/s/ 

split before 

j 

CL /s/ 

concatenate 


1 

Text inspection | 

I Tn 

type n lines 


| 

1 TLn 

ditto, with line numbers 


T + 

type to high water 


1 TL + 

ditto, with line numbers 


1 TBUFFn 

type buffer n 


| File and buffer control 


C /s/ 

commands from s 


C BUFF n 

I 

commands from buffer n (destructive) 



I 


I 
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C COPY n 

commands from buffer n 

FROM BUFF n 

select buffer n as source 

TO BUFF n 

select buffer n for output 

TBUFFn 

type contents of buffer n 

DBUFFn 

delete contents of buffer n 

DBUFF 

delete contents of all buffers 

SHBUFF 

show non-empty buffer numbers 

TO / s/ 

select dsname or ddname 

TO 

select TO 

FROM / s / 

select dsname or ddname 

FROM 

select FROM 

CF 

close all (closeable) files 

CF /s/ 

close file with ddname s 

Conditionals and loops 

Wherever ELSE may appear, the forms 

ELIF se THEN ■ 

eg ELSE eg 

ELUL se THEN eg ELSE eg 

may also appear. 


IF se THEN eg ELSE eg 

UL se THEN eg 

ELSE eg 

IFEOF eg ELSE 

eg if end-of-file 

ULEOF eg ELSE eg unless end-of-file 

WH se eg 

while 

UT se eg 

until 

UTEOF eg 

until end-of-file 

RPT eg 

repeat indefinitely 

AGP 

abandon group 

Margins 


MAn m 

source margins 

MAVn m 

verification margins 

Fixed format fields 


MFnl n2 ... 

mark fields 

Knl n2 ... 

temporarily suspend fields 

Jusification 


JLn 

set justification length 

J s\v 

enable/disable justification 

RJn m 

restrict justification 

VJ sw 

justification verification 

Global operations 


GE q/s/t/ 

global exchange 
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GA q/s/t/ 

GBq/s/t/ 

ON se eg ELSE eg 

CGn 

DGn 

EGn 

SHGn 

VG svv 


global after 
global before 
complicated global 
cancel global n 
disable global n 
enable global n 
show global n 
global change verification 


State display 

SHD 

SHF 

SHG 

SHS 


show data 
show files 
show globals 
show switches 


Termination 

W 

Q 

STOP 


windup 

quit (exit command level) 
sic (return code 8) 


Line verification 

V sw 
VJ sw 
VG sw 
VN sw 
VT sw 
VWR sw 
VWL sw 
VW sw 
VE sw 

I 


automatic verification 
justification verification 
global change verification 
verify line numbers 
verify line texts 
verify right window 
verify left window 
verify both windows 
verify edit lines 

verify with character indications 
verify current line 


Procedures 

PROC name eg define 

SHPROC name show 

CPROC name cancel 

DO name obey 


Hexadecimal mode 

X sw 


switch hexadecimal mode on/off 


Miscellaneous 

Z/s/ 

TR sw 
SQ sw 
SQS sw 
Ha 


set terminator string 
trailing spaces 

sequence numbers in output 
source sequence numbers 
halt at line a 
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COMM /s/ 

comment to verification file 

COLS 


COLS n 

> verify column numbers 

COLS + 

J 

CS sw 

compress spaces 

= n 

set line number 

BRK sw 

enable/disable BREAK 

REWIND 

sic 

MXLLn 

max line length 

SCC sw 

suppress control characters 

SO sw 

suppress overflow errors 

FLUSH 

flush output queue 

STACK n 

set stack size to n bytes 

MXSS n 

set maximum store size to n bytes 

STORE 

show store usage 

MS sw 

monitor store usage 
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